SGI Developer Toolbox 6.1

home *** CD-ROM | disk | FTP | other *** search

/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 1.iso / toolbox / FAQs / SGIfaqs / ExabyteHowTo-faq < prev next >

Wrap

Text File | 1996-11-11 | 23.1 KB | 554 lines

attached is a doc for adding exabyte tape drives for sgi machines. it explains lots of the junk in all the device & kernel config files. also, look at the MLOAD(4), LBOOT(1M), and ML(1M) man pages to understand what the mysterious letters in the master.d/* configuration files mean. ------- begin EXABYTE_SGI_NEED_TO_KNOW file ------------- From: mangalam@uci.edu (Harry Mangalam) Newsgroups: comp.sys.sgi.hardware Subject: EXABYTE HOWTO FOR SGIs Date: 6 Jan 1994 06:55:25 GMT Organization: Microbiology and Molecular Genetics, UC Irvine Here it is; a primitive "HOWTO" about getting EXABYTE tape drives to work on SGI's. To be accurate, this is how I got an ANDATACO-supplied EXB-8505 to give me backup rates of about 0.5 MB/s from an Indigo^2 running 4.0.5H - your mileage will vary. (This is not a plug for any particular EXABYTE supplier - they all buy from EXABYTE, repackage them, and ship them out the door, with varying amounts of value added. ANDATACO simply had the best price for the drive I needed at the time and their tech support turned out to be quite acceptable). Thanks to Harry Shamansky (The ElectroScience Laboratory, Ohio State), John Valdes (Dept of Geophysical Sciences, U. Chicago), Sam Fulcomer (Brown U), Chuck McCalister (EXABYTE) and of course the weightless one (Dave Olson) for advice, corrections and pointers, although errors that have crept thru or remain uncorrected are mine. Warning: This advice is free and therefore worth exactly that much. Heed at your own risk! Verify! Verify! Verify! EXPLICIT WARNING: There is a VERY IMPORTANT GOTCHA here. If you modify the files as described below, make backups using the modified drivers, and then you have a system disk crash, the UNMODIFIED kernel that you load from a CD will almost certainly NOT be able to read your tapes to restore your system and data. To wit, the following exchange: >From John Valdes: "If I use the exabyte for system backups, using the standard 8200 mode (nsv, or compressed mode, 8200c), what are the implications of the above when trying to restore a crashed system disk? With a crashed system disk, I'd have to boot from cd, and in particular, I'd have to boot a kernel w/o my tpsc mods, one which presumedly thinks the exabyte is a QIC drive. From my previous experience, I would have to conclude that I would be unable to read my backup tape. Is this correct? If this is true, then would it be possible to write a tape with the exabyte in a manner so that it would be readable by the tpsc driver as if it the exabyte were a QIC drive? What device file should I use (non-variable, no-swap?) and what blocksize (for mt setblksz)?" Dave Olson replies: "You are correct. So if you want a full tape to be restorable in the miniroot, *with the miniroot kernel*, and the drive type is unknown, you want to write the backup with 512 byte blocks, in fixed block mode. Or, at least backup your kernel in the first tape file, and use 512 byte blocks (fixed or variable) to do that first tape file." So make sure that you have at least the minimal system and files required to finish the restore on a tape that has been written with the above parameters! OK, on with the show: SGI's come with minimal support for Exabytes: There is some support for the 8200 and 8500, but unless you like tracking code, it's not well documented. Without doing the gymnastics described below, it may work - the OS may detect it correctly if it's an 8200 or 8500, and even if not, you may get it to work with the generic SCSI tape driver (which thinks it's a QIC tape), but your transfer rates will probably be abysmal; mine were ~ 70-140 KB/s). The important files are: /usr/sysgen/master.d/tpsc - contains data for the device drivers including the SCSI tape drivers that are of interest here. (In IRIX 5.1, it's /var/sysgen/master.d/tpsc and in 5.2 it's /var/sysgen/master.d/scsi, for reasons best explained by Dave Olson.) /dev/MAKEDEV - a script that when executed, makes the device drivers (actually the 'device special files') according to info detected by the OS and info found in the device files in "/usr/sysgen/master.d" . /dev/rmt/tps...., /dev/mt/tps.... - the device driver files that are created by MAKEDEV to provide access to the tape drive (there is no difference between the two sets of files - in IRIX 5.1, /dev/mt is a link to /dev/rmt). For the Exabytes, they will typically be grouped like this: tps1d4nrnsv.8200 tps1d4nrnsv.8200c tps1d4nrnsv.8500 tps1d4nrnsv.8500c ^ ^^ ^ ^ ^ ^ | || | | | | - compression enabled or not | || | | | - drive emulation | || | | - variable blocking enabled | || | - no (byte) swapping | || - no rewind on close | | - SCSI ID # (detected by OS) | - SCSI controller number (detected by OS) To take advantage of the different features of the drive, you have to access it via the appropriate driver ie. if you want to take advantage of variable blocking that can significantly increase the efficiency of transfer, you have to specify a driver that supports it (tps1d4nsv.8500c, for example). If you consistently use one driver, you should make a symbolic link to it from /dev/tape ie. # mv /dev/tape /dev/tape.orig # ln -s /dev/rmt/tps1d4nsv.8500c /dev/tape so that any access you make to the tape will be via the appropriate driver. The MAKEDEV script creates a link to *an* appropriate driver, but it may not be the one you want to use, hence the above contortion. It is a good idea to use a 'rewind-on-close' driver as a default so that you don't leave the tape in a non-rewound state to mess up the next user (ie. don't use a driver containing the 'nr' setting). To modify the above-mentioned files "/usr/sysgen/master.d/tpsc" and "/dev/MAKEDEV": 1) Make backups of them! 2) Modify "/usr/sysgen/master.d/tpsc" so that it corresponds to your configuration - the appropriate section of my "/usr/sysgen/master.d/tpsc" is shown below. . . . /* There are now 3 densities, 8500c/8505 mode, 8500 mode and 8200. * If someone make bogus dev numbers using all 4 density bits, * it will default back to 8500c mode. The inventory string sets * the drive up exactly like the 8500. */ { EXABYTE8200, TP8MM, 7, 8, "EXABYTE", "EXB-8200", 1, "\16", {0, 0, 0, 0}, MTCAN_BSF|MTCAN_BSR|MTCAN_PREV|MTCAN_CHKRDY|MTCAN_VAR|MTCAN_SETSZ| MTCAN_SILI|MTCAN_CHTYPEANY, 80, 4*60, 25*60, 5*60, 1024, 128*1024}, { EXABYTE8500, TP8MM, 7, 8, "EXABYTE", "EXB-8500", 6, "\40\4\16\0\200\7", {0x0, 0x14, 0x0, 0x0}, MTCAN_BSF|MTCAN_BSR|MTCAN_PREV|MTCAN_CHKRDY|MTCAN_VAR|MTCAN_SETSZ| MTCAN_SILI|MTCAN_CHTYPEANY|MTCAN_SETDEN|MTCAN_SPEOD|MTCAN_SYNC| MTCAN_SEEK, 80, 4*60, 25*60, 5*60, 1024, 128*1024}, { EXABYTE8500, TP8MM, 7, 8, "EXABYTE", "EXB-8505", 6, "\40\4\16\0\200\7", {0x8c, 0x15, 0x90, 0x14}, MTCAN_BSF|MTCAN_BSR|MTCAN_PREV|MTCAN_CHKRDY|MTCAN_VAR|MTCAN_SETSZ| MTCAN_SILI|MTCAN_CHTYPEANY|MTCAN_SETDEN|MTCAN_SPEOD|MTCAN_SYNC| MTCAN_SEEK, 80, 4*60, 25*60, 5*60, 1024, 128*1024}, The sequence that makes up the 2nd line of each stanza ("{0x8c, 0x15, 0x90, 0x14}," for the EXB-8505) is significant for the default settings. See below. Also, Harry Shamansky uses another trick to extract use and compression stats from his drive; see Footnote [1] at end. +++++++++++++++++++++++++++++++++++++++++++++++++++ For the /dev/MAKEDEV modifications, it is similar - here is my interpretation, starting with the pre-existing EXB-8500 stanza: *Device:*EXB-8500*) \ set v nrv nsv nrnsv ; \ for add in 4 5 6 7 ; do \ mdev=`expr $$minor + $$add`; \ mknod $${prf}$$1 c $$maj $$mdev; \ shift; \ done; \ for dens in 0 8 ; do \ case $$dens { \ 0) kden=8500;; \ 8) kden=8200;; \ }; \ set "" nr ns nrns v nrv nsv nrnsv ;\ for add in 0 1 2 3 4 5 6 7 ; do \ mdev=`expr $$minor + $$add + $$dens`;\ mknod $${prf}$$1.$$kden c $$maj $$mdev;\ shift;\ done; \ done ;; \ *Device:*EXB-8505*) \ set v nrv nsv nrnsv ; \ for add in 4 5 6 7 ; do \ mdev=`expr $$minor + $$add`; \ mknod $${prf}$$1 c $$maj $$mdev; \ shift; \ done; \ for dens in 0 8 16 24; do \ case $$dens { \ 0) kden=8500c;; \ 8) kden=8500;; \ 16) kden=8200c;; \ 24) kden=8200;; \ }; \ set "" nr ns nrns v nrv nsv nrnsv ;\ for add in 0 1 2 3 4 5 6 7 ; do \ mdev=`expr $$minor + $$add + $$dens`;\ mknod $${prf}$$1.$$kden c $$maj $$mdev;\ shift;\ done; \ done ;; \ Note that I've re-arranged the "kden=" statements to put the drive in '8500c' mode by default - the order has to correspond to the "{0x8c, 0x15, 0x90, 0x14}," order in the EXB-8505 stanza in the "/usr/sysgen/master.d/tpsc" file. After you've done this, reboot, allow the autoconfig at restart, and then run the MAKEDEV script (# MAKEDEV tps) to make the tape drivers. You should end up with an 'ls' of the /dev/mt and /dev/rmt that looks something like: mt% ls tps1d4* tps1d4 tps1d4nrns tps1d4nrv tps1d4nsv tps1d4.8200 tps1d4nrns.8200 tps1d4nrv.8200 tps1d4nsv.8200 tps1d4.8200c tps1d4nrns.8200c tps1d4nrv.8200c tps1d4nsv.8200c tps1d4.8500 tps1d4nrns.8500 tps1d4nrv.8500 tps1d4nsv.8500 tps1d4.8500c tps1d4nrns.8500c tps1d4nrv.8500c tps1d4nsv.8500c tps1d4nr tps1d4nrnsv tps1d4ns tps1d4v tps1d4nr.8200 tps1d4nrnsv.8200 tps1d4ns.8200 tps1d4v.8200 tps1d4nr.8200c tps1d4nrnsv.8200c tps1d4ns.8200c tps1d4v.8200c tps1d4nr.8500 tps1d4nrnsv.8500 tps1d4ns.8500 tps1d4v.8500 tps1d4nr.8500c tps1d4nrnsv.8500c tps1d4ns.8500c tps1d4v.8500c Now you can try out the drivers with bru, tar (I use the FSF/gnu tar), dump, etc and verify (!) that the drivers are working correctly (or at least working considerably better). A few remaining points that still troubled me: After doing the preceding, I was able to increase the transfer rate from an initial ~70 KB/s to ~500 KB/s, which was good, but not considering that the drive is supposed to be capable of 1MB/s (Sam Fulcomer has reported 700KB/s from a Challenge/IRIX 5.1 combination). On my tape drive, I can set both 8200/8500 mode and compression/no compression by a pushbutton. There is no appreciable difference in transfer rate between the comp/no comp setting, although the LED that signals compression indicated that it is ocurring. With compression on, I typically get over 0.5 MB/s tranfer when backing up binary files and only about 300 kB/s when backing up text files. I expected the reverse to be true. What gives? The answer has to do with the fact that the rate at which data goes on the tape depends on how fast the SCSI channel can be filled (although 1 MB/s should be no problem for even a SCSI-1 controller), how efficient the compression is, and most importantly, how much overhead there is for the amount of data going on the tape. Large files have less overhead than small ones and although it seems counter- intuitive, I get faster transfer of binaries than of text. Footnotes: [1] Harry Shamansky used a neat but possibly dangerous (for novices) approach to extract stats from his drive after a backup; the stats are normally cleared because of the way that SGI has decided that the drive should left. Harry S's approach (NOT supported by SGI): Here's the stuff I use. One note, however. There are two conflicting considerations. If you desire compression statistics, then you should set the drive up as TPUNKNOWN, since SGI feels that the omission of a trailing EOD on the no-rewind device is a bug. [We don't, and we like stat's, so we set it this way] If you do, then hinv will respond with "unknown" as the type, as will mt -status, but this has no effect on the drive overall. (If you want more specifics about this isue, let me know, we have the complete details.) Otherwise, use TP8MM in place of TPUNKNOWN, but the compression statistics will be lost. <<Warning from Dave Olson: The above is true *only* if you have made other mods so that TPUNKNOWN is basicly the same as an exabyte. {The reason that SGI does not support this approach is} the exabyte drive will leave the tape in a trashed state (no eod mark, which causes all kinds of drive (*NOT* driver) problems when reading up to that point later on, if the system is shut down without the tape being rewound/unloaded, etc., OR a SCSI bus reset occurs before the rewind).>> Here's our mod to /usr/sysgen/master.d/tpsc - add the comments to the Exabyte stanza; append the driver description to that already existing (I've included the apprpriate bit of my "/usr/sysgen/master.d/tpsc" afterwards): /* There are now 3 densities, 8505 mode, 8500 mode and 8200. * If someone make bogus dev numbers using all 4 density bits, * it will default back to 8505 mode. The inventory string sets * the drive up exactly like the 8500. */ /* Note that the TPUNKNOWN is needed to workaround the move that SGI makes when they handle a TP8MM after write (i.e. a bsFM, then fsFM) which clears the compression statistics) */ { TPUNKNOWN, TPUNKNOWN, 7, 8, "EXABYTE", "EXB-8505", 6, "\40\4\16\0\200\7", {0x8c, 0x15, 0x14, 0x8c}, MTCAN_BSF|MTCAN_BSR|MTCAN_PREV|MTCAN_CHKRDY|MTCAN_VAR|MTCAN_SETSZ| MTCAN_SILI|MTCAN_CHTYPEANY|MTCAN_SETDEN|MTCAN_SPEOD|MTCAN_SYNC| MTCAN_SEEK, 80, 4*60, 25*60, 5*60, 1024, 128*1024}, If you have an 8500c drive instead/as well, then you can simple replace/copy the above and replace "EXB-8500" with "EXB8500C". NB: Know what you're doing before you try this!! And his mods to "/dev/MAKEDEV" In /dev/MAKEDEV, it's rather simple. We prefer to have the compression on by default, hence our 0) setting points to the 0x8c desnity seen above in tpsc: *Device:*EXB-8505*) \ set v nrv nsv nrnsv ; \ for add in 4 5 6 7 ; do \ mdev=`expr $$minor + $$add`; \ mknod $${prf}$$1 c $$maj $$mdev; \ shift; \ done; \ for dens in 0 8 16; do \ case $$dens { \ 0) kden=8505;; \ 8) kden=8500;; \ 16) kden=8200;; \ }; \ set "" nr ns nrns v nrv nsv nrnsv ;\ for add in 0 1 2 3 4 5 6 7 ; do \ mdev=`expr $$minor + $$add + $$dens`;\ mknod $${prf}$$1.$$kden c $$maj $$mdev;\ shift;\ done; \ done ;; \ (obviously the same comments hold for the 8500c above) HS also has a couple of programs that assist in extracting the stats - you should contact him for the details: hts@hertz.eng.ohio-state.edu. Let me know if anyone has problems with this approach, or can point out a better one. Cheers and Happy New Year! Harry Harry Mangalam, VCO/Micro+Mol Genetics, Irvine Hall, Coll of Med, UC Irvine, Irvine, CA, 92717, Vox:(714) 856-4824, Fax:(714) 725-2118, mangalam@uci.edu --- Life is messy --- Newsgroups: comp.sys.sgi.admin,comp.sys.sgi.hardware From: doctor@kronos.arc.nasa.gov (Terry Fong) Subject: Exabyte 8205 WORKING! Summary: using an 8205 to read/write 8200 format tapes Keywords: Exabyte, 8205 Organization: NASA ARC/ Information Science Division Date: Fri, 7 Jan 1994 20:22:32 GMT Hi all, Just wanted to publicly thank Dave Olson for his help in getting my Exabyte 8205 drive working properly. If you missed my previous posts, I recently installed an 8205 on a 4D/30 and have since been trying to get it to read & write tapes which can be used on a Sun attached 8200. The solution is as follows: 1) Modify /usr/sysgen/tpsc/master.d to add support for the Exabyte 8205 (my drive came from Andataco) by adding the following: /* The following is entry adds support for an Exabyte 8205. The * 8205 is not supported by SGI under IRIX 4.0.5 * */ { EXABYTE8500, TP8MM, 7, 8, "EXABYTE", "EXB-8205", 6, "\40\4\16\0\200\7", {0x14, 0x90, 0x90, 0x90}, MTCAN_BSF|MTCAN_BSR|MTCAN_PREV|MTCAN_CHKRDY|MTCAN_VAR|MTCAN_SETSZ| MTCAN_SILI|MTCAN_CHTYPEANY|MTCAN_SETDEN|MTCAN_SPEOD|MTCAN_SYNC| MTCAN_SEEK, 80, 4*60, 25*60, 5*60, 1024, 63*1024}, ^ |--- see below Note: Harry Mangalam's "EXABYTE HOWTO FOR SGIs", which was posted recently suggests using "128" instead of "63". This is okay if you are only going to read tapes on an SGI. If, however, you want to be able to read your tapes on a Sun, you have to use "63". In Dave Olson's words: | Change the 128 to 63, and Sun systems will be a lot happier (assuming | you are using the variable block devices. Sun, for reasons best known | to them, won't do > 64K DMA, and translated that into the largest | block size they write; they do some godawful things with sizes > | 64KB-2 bytes. This isn't necessary if the 8200 is on another | SGI system, but it sounds like for you, they are all on Suns. Also, this entry specifies the four densities {0x14, 0x90, 0x90, 0x90} which correspond to {8200 mode, 8200 compressed mode, 8200 compressed mode, 8200 compressed mode}. 2) Modify /dev/MAKEDEV and add the following to create devices: *Device:*EXB-8205*) \ set v nrv nsv nrnsv ; \ for add in 4 5 6 7 ; do \ mdev=`expr $$minor + $$add`; \ mknod $${prf}$$1 c $$maj $$mdev; \ shift; \ done; \ for dens in 0 8; do \ case $$dens { \ 0) kden=8200;; \ 8) kden=8200c;; \ }; \ set "" nr ns nrns v nrv nsv nrnsv ;\ for add in 0 1 2 3 4 5 6 7 ; do \ mdev=`expr $$minor + $$add + $$dens`;\ mknod $${prf}$$1.$$kden c $$maj $$mdev;\ shift;\ done; \ done ;; \ This will create the appropriate devices (i.e., tps0d3nsv.8200, tps0d3.8200c, etc.). 3) autoconfig, run /dev/MAKEDEV, and reboot. Once this is done, you can create tapes on the 8205 (in 8200 mode) which can be read by a Sun's 8200. Just use the non (byte) swapping, variable blocking device (e.g., "/dev/mt/tps0d3nsv.8200") when making tapes. This is required since Sun's always use non (byte) swapping, variable blocking devices. ------------------------------------------------------------------------------ To make a dump tape of "/", for example, use the following on the SGI: dump 0bdfsu 56 54000 /dev/mt/tps0d3nrnsv 6000 / Note that blocking is specified to be "56" since Sun's mtio(4) can only r/w a maximum of 65535 bytes and 56 KB is the highest multiple of 8 KB less than 65535 (see SGI's dump(1M) for details). This tape can then be read on a Sun's 8200 using restore: restore if /dev/nrst1 ------------------------------------------------------------------------------ To make a tar tape, on the SGI: tar cvf /dev/mt/tps0d3nsv blah... This tape can then be read on a Sun's 8200 using: tar bxvf 126 /dev/rst1 ------------------------------------------------------------------------------ Thanks again Dave! Cheers, Terry Fong NASA Ames Research Center -- _______________________________________________________________________________ "You do not understand anything Terry Fong <terry@ptolemy.arc.nasa.gov> until you understand it in more NASA Ames, M/S 269-3, Moffett Field, CA than one way..." -- Marvin Minsky (415) 604-6063, (415) 604-6081 lab From: olson@anchor.esd.sgi.com (Dave Olson) Newsgroups: comp.sys.sgi.hardware Subject: Re: EXABYTE HOWTO FOR SGIs Date: 8 Jan 1994 08:24:17 GMT Organization: Silicon Graphics, Inc. Mountain View, CA In <2gi37gINN3p1@network.ucsd.edu> sd@chem.ucsd.edu (Steve Dempsey) writes: | Harry Mangalam writes: | > SGI's come with minimal support for Exabytes: There is some support for | >the 8200 and 8500, but unless you like tracking code, it's not well | >documented. Without doing the gymnastics described below, it may work - | >the OS may detect it correctly if it's an 8200 or 8500, and even if not, | >you may get it to work with the generic SCSI tape driver (which thinks it's | >a QIC tape), but your transfer rates will probably be abysmal; mine were ~ | >70-140 KB/s). | | Now you've got me worried. I've been using 8200 and 8500 Exabytes on | a 4D/25 at 4.0.x for three years, and on a Challenge at 5.0.1 since last March. | I've never had a bit of trouble with them. I never had to modify the kernels, | and I've always been able to achieve the advertised transfer rates (240KB/sec | for the 8200, 500KB/sec for the 8500). I've even been able to read the tapes | from a miniroot. | | Have I just been lucky, or do these changes apply only to enabling the | data compression features? I thought that this part was going to get reworded... It's accurate in some sense, but misleading. SGI supports, and is fully functional, for the 8200 and 8500, and the performance for the drives we ship is close to what the drive can achieve. 3rd party drives may vary. 8205 and 8505 and 8[25]0[05]C drives aren't officially supported, but can mostly be made to work pretty well. SGI no longer sells Exabytes on the "low end" systems, and officially they aren't supported (except for those we sold for those in the past, i.e., we "officially" don't support them on new systems/purchases), but since the driver is identical, they do in fact work, and I believe all the support folks don't worry about the technicality. -- The most beautiful things in the world are | Dave Olson those from which all excess weight has been | Silicon Graphics removed. -Henry Ford | olson@sgi.com